Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9707/000005_owner-urn-ietf _Thu Jul 24 14:59:30 1997.msg

Internet Message Format | 1997-07-31 | 6KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id OAA14902
    for urn-ietf-out; Thu, 24 Jul 1997 14:59:30 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA14897
    for <[e-mail]>; Thu, 24 Jul 1997 14:59:27 -0400 (EDT)
Received: from beethoven.bunyip.com (beethoven.Bunyip.Com [192.197.208.5])
    by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA04550
    for <[e-mail]>; Thu, 24 Jul 1997 14:59:26 -0400 (EDT)
Received: from localhost (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) with SMTP id OAA22509 for <[e-mail]>; Thu, 24 Jul 1997 14:59:26 -0400
X-Authentication-Warning: beethoven.bunyip.com: leslie owned process doing -bs
Date: Thu, 24 Jul 1997 14:59:25 -0400 (EDT)
From: Leslie Daigle <[e-mail]>
To: [e-mail]
Subject: [URN] strawcat proposal
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: Leslie Daigle <[e-mail]>
Errors-To: [e-mail]


----------------------------------------
Preamble:
----------------------------------------


In Memphis, there was much debate about who should  or should not
be deemed eligible to "have" a namespace -- e.g., only multi-national
organizations.  What could those identifiers be -- some suggested there
are too many socio-political problem areas with letters (of any character
set), so we'd best stick with numbers, and perhaps assigned ones at that
(and anyone else that has read C. J. Cherryh's Atevi books will point out
the potential problems of being assigned infelicitous numbers, but that's
a different earth... ;-)

It has often been pointed out on this list that we, the URN group, and
the IETF in general, are not in a position to _enforce_ much of anything
in the way of socio-political requirements.  We need a technical system that
works irrespective of the wars raged in those areas.

And, we have people who want to set up URN namespaces _now_ -- having read
the URN syntax document, they have a clear idea of how the would like their
URNs to be structured, but maybe haven't thought a lot about how the
resolution service will be set up and maintained and linked into the
global infrastructure.

We've discussed some of this before, and some of this does already appear
in Renato and Patrik's document, but I'd like to step away from that for
a moment, to just focus on what we need to have written _somewhere:

We can write up the list of technical _expectations_ of a namespace, AND
namespace serving:

    . no identifier reused
    . mapping from identifier to URN syntax (in the case of grandfathering)
    . no forseen reasons that the namespace resolution service(s) will be
      terminated before the URN references are all deleted
    . registration in the Global NID registry
    . fall-back plans for passing off resolution of the namespace in
      the event that the entity defining the namespace ceases to exist
    . <etc>

This at least gives some guidelines for people who think they want a
URN namespace.

Then, we can write up a list of guidelines for _good_ namespaces and
namespace serving:

    . if a namespace that works already exists, use it
    . it's better if it demonstrates multi-national applicability
    . <etc>

So, then, what is the process for defining a namespace?  Do you define
a NID, set up a tHTTP server, and start resolving those?  Are these valid
URNs?  Is it valid if you send in the appropriate NAPTR information to
be registered in the urn.net domain?  Should each and every proposed namespace
be put through an RFC-definition process?

----------------------------------------
Proposal:
----------------------------------------

Here comes the strawcat proposal for naming conventions:

    . reserve "std-" prefix in NIDs for those namespaces that have
      gone through a technical review within the IETF and for which
      there is an RFC describing the namespace and its conformance
      to the guidelines.  (Then, Ryan's proposed namespace would
      be "std-ietf").

    .. use "prv-" prefix for NIDs of any other namespace (which _can_
      be registered in the urn.net domain).

This is meant to draw on what I've  understood is the approach used with
MIMEtypes -- the "vnd." subtypes for vendor-defined types.  It means that
namespaces can be set up fairly easily for those who don't forsee the need for
URNs outside their own space -- but if these URNs do escape (and
they will) they can still be recognized/handled in the global context.  The
theory is that, if a namespace has been put through the full technical
definition to become an std- namespace, then the proposer was serious enough
about it to be a reasonable bet for providing the necessary longterm
infrastructure for serving it.  No guarantee -- we aren't about guarantees.
It also provides a mechanism for distinguishing between the two types.  And,
if  "foo" is first defined as a private namespace ("prv-foo"), and then
made a standard ("std-myfoo", because "std-foo" is something else),
the Global NID can map the existing "prv-foo" URN resolution to the same
servers as the "std-myfoo".


Anyway, this is just a proposal, meant to kick off some discussions about
the issues in the area.  I'm climbing into my flame-retardant suit and
awaiting feedback... :-)

Leslie.


----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you
                          _are_."                 Bunyip Information Systems
                                                  [phone]
                      -- ThinkingCat              [e-mail]
----------------------------------------------------------------------------